저는 CRUD의 세계나 SI나 DB나 업무 시스템은 잘 모르는 개발자입니다...만..
여튼.. 시대가 21세기가 됐으므로 어지간한 로직에서는 CRUD에서 U와 D를 좀 없애고 설계하자는 입장이다. 히스토리 관리가 필요한 경우 복잡한 히스토리 연관 테이블을 꾸미는 것도 일이고 해서 U나 D가 발생하는 일은 status 테이블을 구축하여 시간이나 시퀀스 넘버를 적고, max(그거)로 참조하는 방식을 주장하는 편이다. 아마도 금융권 트랜잭션이나 정부 관련 업무는 이미 IT의 태동기때부터 그렇게 하고 있으리라고 짐작은 해보는데 그쪽 전문가가 아니니 실상을 알 수는 음따. 복잡한 히스토리 연관 테이블의 미로를 기가 막히게 짜놨을수도 있고..
그리하야 오래된 데이터는 콜드 데이터 영역으로 내빼버리고 빠릿하게 나와야 할 놈들은 핫 데이터 영역에 유지하고 캐시도 태우고 복짝복짝...
시스템 프로그래밍 입장에서도 이게 유리헌디 파일의 중간에 가서 수정하겠다고 쪼물락쪼물락 할 일이 없다. 끝에다만 붙이믄 됭께. 하드디스크의 구조나 SSD 세계의 드릅고 복잡다난한 블럭 머지/스플릿을 생각하면 더욱 그렇다.
그르나 생각해보니 컬럼 수가 드릅게 많으면 필시 테이블을 쪼갤텐데 각 테이블의 최종 데이터를 복사해와서 신규로 C를 하거나 각 테이블의 ID 전부를 status 테이블에서 관리해야 하고 그거 자체는 그리 품이 안 드는 일이나 트랜잭션 원자성 측면을 생각해보면 어택 구간이 많아서 조금 거시기 해분다. 아.. 내가 잘못생각했나.. 이 글 내리겠습니다..
어쨌든.. 21세기에 있어서 예쁘고 잘 나뉜 ERD는 나는 그닥 찬동하지 않는 편인데, 중간에 텅텅 비어도 좋으니 그냥 테이블 짜개지 말고 쓰는 건 또 어떠냐는 주의다. 텅텅 빈거야 DB가 잘 해줄 일이지 왜 내가 신경쓰. 아마도 요즘 DB는 글케 잘 돼 있을 것 같긴 하다. 노SQL은 기본일 것 같고. libsvm 포맷팅을 보라. 허허벌판을 얼마나 잘 지원하는가. (근데 왜 넌 문자냐..)